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REMARKS 

This paper is responsive to the Office Action dated February 24, 2004. All rejections and 
objections of the Examiner are respectftilly traversed. Reconsideration is respectfully requested. 

At paragraphs 2-3 of the Office Action, the Examiner rejected claims 1-33 as being 
obvious under 35 U.S.C. 103, citing the combination of United States patent number 5,983,274 
of Hyder et al. (" Hvder et al." ") and United Slates patent number of Dobbins et al. 5,509,123 
(" Dobbins et al. ""). Applicants respectfully traverse Ais rejecdon. 

Hvder et al. disclose a system for creation and use of control information associated with 
packetized network data by protocol drivers and device drivers. The Hyder et al. system is 
designed to allow a software component that processes network data to communicate control 
information to, and cooperate with, another software component by associating control 
information with a packet of network data. The Hvder et al. system associates control 
information with network data upon w*iich control information will operate by appending one or 
more control data structures to a packet descriptor that is common to ail software components 
processing the network data. The control data structure in Hvder et al. is "tagged" with a class ID 
value that allows other software components to recognize and utilize the control infonnation. 
Hvder et al. intend their system to enable any software component to cooperate v^th and 
communicate to another software component that processes the network data regardless of any 
intervening software components. 

Hvder et al. use the term "direct call linkage" to refer to a function call interface in their 
system. As discussed by Hvder et al., address resolution may be done al compile time through 
traditional linker programs, or may be done dynamically by system components when using such 



978 284 9119 T-782 P. 011/017 F-821 

Art Unit: 2126 



PAGE 11/17' RCVD AT $124/2004 1:37:52 PM [Eastern DayligMrime]'SVR:USPTO{FX^^^^^ 



04-May-2d 12:10pm Frora-Steubing.McGuiness & Manaras LLP 978 264 9119 T-7B2 P. 012/017 F-621 

Serial No. 09/536,078 - 9 - Art Unit: 2126 

entities as dynamic link libraries or export libraries, Hvder et al. teach that network data may 
contiguously reside in a memory buffer or may be accessed by indirect means or structures such 
as Memory Descriptor Lists (MDL's) that map segments of virtual memory and tlieir physical 
page size, and that memory may be requested by a transport protocol driver or a network device 
driver through an interface call to an integrating component which in tum manages allocating 
memory. In this way, Hvder et al. teach that network data is made accessible from a packet 
descriptor. 

The packet data stmcture of Hvder etal. also includes a pointer to a series of control data 
stmctuies. Each control data structure in the series of control data structures of Hyder et al. is 
created by an originating software component, such as the transport protocol driver, the network 
card device driver, or other component that in some way processes the packet, and is filled with 
control infoimation that will eventually be used by another software component other than the 
component creating the data strucmre as the packet descriptor, including all data referenced 
therefrom, is passed or sent to other software components by means of the integrating software 
component. Thus the packet descriptor of Hvder et al, fimctions as an integrating data stmcture 
to tie together the network data and the series of control data structures. 

Dobbins et aL disclose an object-oriented architecture for network layer routing, which 
distributes fimction and system behavior into autonomous router software objects. Dobbins et al. 
describe distributing fimctionalities into each object, so that services and data normally external 
to an object are imbedded or accessible within the object itself. Dobbins et al. further teach that a 
separate forwarding engine may be provided at each network interface of a networking device. 
Objects such as these separate forwarding engines are described by Dobbins et al. as having (1) 
common, protocol-independent functions that are shared by all objects of that class; (2) their own 



PAGE 1 2/1 7 * RCVD AT 5/24/2004 1 :37:52 PM [Eastern Daylight Ti^^^ 



04-May-24 tZHOpm Frorn-Steubing.McGuiness & Manaras LLP 978 264 9119 T-782 P. 013/017 F-621 

Serial No. 09/536,078 -10- Art Unit: 2126 

configuration information; (3) accessibility through a router resource object for instantiation and 
control; (4) automatic persistence in NVRAM; (5) remote management capabilities; and (6) text 
names for navigation of a resource tree as a file system, Dobbins et al. provide that such 
capabilities are in every object regardless of the specific protocol or application, in order to 
ensure a common architecture among many different systems/router components, a common 
method of control internally, a consistent order of instantiation and a common functional 
behavior. 

The router objects of Dobbins et al. have three types of imbedded functionality 
automatically built in, including 1) common protocol-independent functions of the object, which 
may be a routing function or a system fiinction, 2) fimctions provided by a base resource object 
class which defines methods and data for configuration and control, and 3) functions provided by 
the managed object class which define the methods and data for network management. 

FIG. 3A of Dobbins et al. shows a three-dimensional view of a system architecture 
including logical relationships between objects, and wherein each functional subsystem is shown 
as a separate "plane." Thus, this system architecture disclosed by Dobbins et al. FIG. 3 A includes 
four hoiizontally disposed planes: 1) routing appUcations, 2) host communications, 3) 
forwarding, and 4) network interfaces. Multiple object instantiations can exist in the Dobbins et 
al. FIG. 3A system, such as forwarding and routing protocol objects instantiated for each 
individual protocol. Connections between the different planes of the Dobbins et al. system are 
described as logical cormections through resource objects and a naming tree. 

In FIG. 4 of Dobbins et al.. distributed autonomous forwarding engines are used instead 
of a single centralized forwarding engine. Each of the forwarding engines of the Dobbins et al. 
system knows how to receive and transmit packets on its own interface, as well as its own 
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configuration infonnation, and how to receive and transmit packets on the associated interface, 
based on a common forwarding table. The specific goal of the each forwarding engine in the 
Dobbins et al, system is to provide the reception, processing, and forwarding of network layer 
packets- Accordingly, all forwarding engines in the Dobbins et aL system perform the same 
basic tasks regardless of protocol or media. In this regard, Dobbins et al describe a service 
function for in-bound processing of a networic layer packet including reception of the packet 
from the data link layer, vaUdation and error piocessing, filter processing, and route lookup 
processing to determine a next hop. A forward function in Dobbins et al, covers the actual out- 
bound processing of a network layer packet, consisting of fiher processing, converting network 
layer address to physical address, and passing the packet to the data link layer of the outbound 
interface for transmission. 

FIG, 8 of Dobbins et aL shows a MIB (Management Information Base) structured as a 
tree, with each node representing an identifier in the Object Identifier (OID). Managed Objects 
are placed at leaf nodes by the Dobbins et al. system, and can be accessed by name or in sequence 
in an authenticated maimer. Dobbins et al. include no reference to Application Programming 

Interfaces (APIs) of any kind. 

Nowhere in the combination of Hyder et al. and Dobbins et al., taken either individually 
or in combination, is there disclosed or suggested any: 



. . . application programming interface to aforwarding plane for processing data 
packets in a network device that forwards packets across a network^ the application 
prograimning interface comprising: 

an input module that receives routing platform independent function calls, 
wherein the function calls include routing j7/fl(/oi7ff independent input control data; 

at least one control module that receives the input control data via the fimction 
calls, the at least one control module producing routing platform specific output control 
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data based upon the input control data, the output control data being capable of 
controlling execution of the forwarding plane; and 

an output module that forwards the output control data from the at least one 
control module. 

as in the present independent claims 1, 9, 18, 21 and 29. Applicants respectfuUy urge that the 
interfaces described in the combined references, and cited by the Examiner, are fax different from 
the claimed invention set forth in the present independent claims. Specifically, an Application 
Programming Interface (API) is described by Hvder et al. as a set of subroutines provided by an 
integrating driver software component, so that relevant services in device drivers may be 
uniformly accessed by protocol drivers. Thus the APIs described in Hvder et ah are used in the 
integrating driver that interfaces between a protocol driver and a device driver. See Claims 1 , 8 
and 2Q of Hvder et al. Hvder et al. include no other reference to APIs. Dobbins et al., come no 
closer to disclosing or suggesting the above highlighted features of the present independent 
claims, gobbms et al. teach protocol-specific Forwarding and Service (FAS) engines derived 
from a common base class, each protocol forwarding engine of Dobbins et al. having a generic 
interface for packet servicing and forwarding* regardless of the specific protocol type. In contrast 
to the presently claimed API features, Dobbins et aL teach a service in which each protocol FAS 
registers a pointer To its base class with a packet dispatcher at the data link level for each 
interface it is instantiated on. This allows a packet dispatcher in the Dobbins et al, system to 
invoke an overloaded virtual service method without having to know protocol FAS specifics. 
The combined teachings of Hvder et al. and Dobbins et al. accordingly provide no hint or 
suggestion of even the desirability of having a system or method including an application 
programming interface to a forwarding plane for processing data packets in a network device 
that forwards packets across a network, in which an input module receives routing platform 
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independent function calls including routing platfoxm independent input control data, and a 
control module that receives the input control data via the function calls and produces routing 
platform specific output control data based upon the input control data, the output control data 
being capable of controlling execution of the forwarding plane, as in the present independent 

claims 1,9, 18, 21 and 29, 

For the reasons stated above. Applicants respectfully urge that the combination of Hyder 
etal. and Dobbins et al. does not disclose or suggest all the feamres of the present independent 
claims I, 9, 18, 21 and 29. Accordmgly, Applicants respectfully iKge that the combination of 
Hvder et al. and Dobbins et al, does not support a. prima facie case of obviousness under 35 
U.S.C. 103 with respect to claims 1, 9, 18, 21 and 29. As to the remaining claims, they each 
depend from claims 1, 9, 18, 21 and 29, and are respectfully believed to be patentable over the 
combination of H yder et al. and Dobbins et al. for at least the same reasons. Reconsideration of 
all pending claims is respectfully requested. 

As all claims are believed to be allowable, the application is believed to be in condition 
for allowance. Withdrawal of the claim rejections and fevorable action are respectfully 
requested. 

Applicants have made a diligent effort to place the claims in condition for allowance- 
However, should there remain unresolved issues that require adverse action, it is respectfiilly 
requested that the Examiner telephone the undersigned Attorney at 978-264-6664 so that such 
issues may be resolved as expeditiously as possible. 
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For these reasons, and in view of the above amendments, this application is now 
considered to be in condition for allowance and such action is earnestly soHcited. 



Respectfully Submitted, 




Attorney/Agent for Applicant(^ 
Steubing McGuinness & Manaras LLP 
125 Nagog Park Drive 
Acton, MA 01720 
(978) 264-6664 
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